receiveQualityNotification

Version: 24.03

Receives a new quality notification

application/json

Request Body

header object required
messageId uuid required
Unique ID identifying the message. The purpose of the ID is to uniquely identify a single message, therefore it MUST not be reused.
context string required
Possible values: [TRACE-QM-Investigation:1.0.0, TRACE-QM-Alert:1.0.0]
The context defines the type of quality notification. The context is chosen by the initiator of a quality notification. The QM-Investigation describes a quality issue top-down when it's sent towards the supplier. The QM-Alert describes a quality issue bottom-up when it's sent towards the customer.

TRACE-QM-Investigation:1.0.0

A quality investigation is used to try and technically narrow down the cause of a suspected problem with a serialized part / batch. To achieve this, a customer who has purchased serialized parts/ batches can request his supplier to investigate the affected serialized parts / batches regarding the suspected problem.

TRACE-QM-Alert:1.0.0

A quality alert is sent by a supplier to a customer and describes identified quality issue(s) in one or more serialized parts/ batches delivered to that customer. Thus, the quality alert - besides other information - contains a list of the affected serialized parts/ batches and a description of the quality issue(s). In the worst case the quality alert can result in a recall of the affected serialized parts/ batches.

The value MUST consist of two parts -- an identifier of the context (e.g. business domain, etc.) followed by a version number. Both the identifier and the version number MUST correspond to the content of the message. Versioning only refers to major versions in both default and fallback cases. Note -- The version of the message's header is specified in the version field.
sendDateTime date-time required
Time zone-aware timestamp holding the date and the time the message was sent by the sending party. The value MUST be formatted according to the ISO 8601 standard.
senderBpn string required
The business partner number (BPN) of the sender. It is set by the initiator (i.e., sender) of the notification.
recipientBpn string required
The business partner number (BPN) of the receiver. It is set by the initiator (i.e., sender) of the notification.
expectedResponseBy date-time
Time zone-aware timestamp holding the date and the time by which the sending party expects a certain type of response from the receiving party.The meaning and interpretation of the field's value are context-bound and MUST therefore be defined by any business domain or platform capability making use of it. The value MUST be formatted according to the ISO 8601 standard.
relatedMessageId uuid
A UUIDv4 to uniquely identify a related quality notification. This field is not about mapping the internal references between quality notifications. This field should only reference the quality notifications that

- the recipient can basically understand in his business context and

- are of concern to the recipient

That means, that in most instances, the sender and receiver of both quality notifications (i.e., the send one and the referenced one) are the same. Examples Due to an QM-Investigation an QM-Alert is created and referencing to the QM-Investigation. An QM-Investigation is followed by another QM-Investigation that is referencing to the same quality issue.
version string required
The unique identifier of the aspect model defining the structure and the semantics of the message's header. The version number should reflect the versioning schema of aspect models in Catena-X.
content object required
notificationId uuid required
A UUIDv4 to uniquely identify a quality notification. This unique ID gets generated by the initiator of a quality notification. The sender and receiver of a quality notification use this unique ID to reference a quality notification.
status string required
Possible values: [CREATED, SENT, RECEIVED, ACKNOWLEDGED, ACCEPTED, DECLINED, CLOSED]
The status of the quality notification. The following entries are supported and allowed

CREATED This status is an internal status and is used after the initial creation of a notification. It is not communicated to an other CX/business partner.

SENT This status means that the notification has been sent out. This status is shown on the sender side (and not on the receiver side).

RECEIVED This status means that the notification has been received by the receiver. The status is shown on sender and receiver side.

ACKNOWLEDGED Defines that a user has confirmed that the notification has been received. This does NOT mean that the user accepted the notification in the sense of an admission of guilt or the like. However, it means that the notification gets processed by the user (or the organization behind).

ACCEPTED The status expresses that the received agrees on the quality investigation/alert. Recommendations, counter actions, and the like can be conveyed in the payload field information.

DECLINED The status expresses that the received does not agree on the quality investigation/alert. Recommendations, counter actions, and the like can be conveyed in the payload field information.

CLOSED This status is set by the initiator of the notification either to regularly close the notification (i.e., after the receiver has set the status to ACCEPTED or DECLINED) or to abort the processing of the notification (e.g., because the notification is not relevant anymore).

severity string required
Possible values: [MINOR, MAJOR, CRITICAL, LIFE-THREATENING]
The severity of the quality notification describes its criticality. The severity is set by the initiator of a quality notification. The following entries are supported and allowed

MINOR This is the case if the quality issue(s) is/are not affecting any functionalities of the serialized parts/batch e.g., aesthetical issue.

MAJOR This is the case if the quality issue(s) is/are so critical that the functionality of the serialized parts/batch is partially not given. This is also the case if the serialized part / batch is no longer functional, but the missing functionality (a) can be compensated by other parts of a superordinate system or (b) has a relatively low significance / benefit

CRITICAL This is the case if the quality issue(s) is/are so critical that the basic functionality of the serialized parts/batch is no longer given.

LIFE-THREATENING This is the case if the quality issue(s) is/are so critical that it even endangers human lives e.g., the airbag or break is not working.

information string
Possible values: <= 1000 characters
A text that e.g. describes the quality alert or the quality investigation. Recommendations or counter actions can be added by the receiver when ACCECPTED or DECLINED the notification.
listOfAffectedItems string[] required
Items are added by the initiator (i.e., sender) of a notification. Once the notification is not in the status CREATED (e.g., it has been sent) the array cannot be changed.

Responses

Quality notification was received successfully

receiveQualityNotification​

receiveQualityNotification